GH-50779: [C++][Parquet] Replace remaining RapidJSON usage with simdjson - #50781

⚠️ GitHub issue #50779 has been automatically assigned in GitHub to PR creator.

@rok @taepper

I'm migrating parquet/geospatial/util_json_internal.cc and ran into an ondemand question.

GeospatialGeoArrowCrsToParquetCrs() needs to:

1. inspect the crs object (e.g. check the id.authority/code fields to detect EPSG:4326/CRS84), and
2. if it isn't a recognized lon/lat CRS, serialize the same object back to JSON.

With RapidJSON this was straightforward because the DOM is reusable, but with simdjson::ondemand the object has already been consumed by the time I want to serialize it, leading to OUT_OF_ORDER_ITERATION.

Is the expected approach here to restructure the code into a single pass, or is there another way to serialize an already-inspected ondemand::object?

Thanks!

As per docs here you could probably use the .reset() in case you don't get desired CRS fields.

  // Inspect crs_object...

  // If it was not a recognized lon/lat CRS:
  ARROW_ASSIGN_OR_RAISE(
      auto ignored,
      ::arrow::internal::GetSimdjsonResult(
          crs_object.reset(), "Failed to reset 'crs' object: "));

  ARROW_ASSIGN_OR_RAISE(
      auto raw_crs,
      ::arrow::internal::GetSimdjsonResult(
          crs_object.raw_json(), "Failed to get raw 'crs' JSON: "));

  return std::string(raw_crs);

Check also rewind and consider what's best for your usecase.

Thanks @rok, reset() + raw_json() fixed the iteration issue.

However, one test still fails because raw_json() preserves the original formatting (e.g. {"key0": "value0"}), whereas the previous RapidJSON Writer minified it to {"key0":"value0"}. LogicalType::Equals() compares the CRS string literally.

Would you prefer keeping the previous compact formatting or preserving the original JSON formatting?

@Reranko05 let's avoid behavior changes. Perhaps we can use simdjson::minify?

@kou @rok @pitrou Could you review this when you have time?

I also see many RapidJSON references in cpp/cmake_modules/ThirdpartyToolchain.cmake. Are we ready to remove those yet? (I don't know, hence the question)

I also see many RapidJSON references in cpp/cmake_modules/ThirdpartyToolchain.cmake. Are we ready to remove those yet? (I don't know, hence the question)

@rok RapidJSON is no longer used by Parquet after this change, so I've removed the Parquet-specific dependency. However, there are still many RapidJSON users elsewhere in Arrow (e.g. arrow/json, arrow/integration, arrow/extension, arrow/flight/sql), so I don't think we're ready to remove the ThirdpartyToolchain references yet.

https://github.com/apache/arrow/actions/runs/31024222689/job/92369046910?pr=50781

We need to fix meson ci due to ../../arrow/cpp/src/arrow/integration/meson.build:26:8: ERROR: Unknown variable "simdjson_dep".

@wgtmac Thanks for pointing it out, I have added the Meson support for simdjson and updated the relevant targets. The Meson CI is now passing.